Identity is well understood in the physical world, but is a current challenge in the digital world. In the physical world, people present a passport at an airport's Immigration Desk, a driver's license to a police officer, a credit card to pay for a best-selling novel at a bookstore, and various other types of identification in a variety of situations. In the digital world, people may log onto websites using a username and password, provide shipping and credit card information to an online retailer, use a smartcard to log onto a corporate network, and so forth.
Numerous systems exist for providing digital identity. The identity metasystem provides a framework for organizing many different types of systems for digital identities. WINDOWS™ CardSpace uses various vendor-neutral communication standards, such as WS-Security, WS-Trust, WS-MetadataExchange, and WS-SecurityPolicy to offer a consistent way to work with any digital identity created by any source, using any identity technology. WINDOWS™ CardSpace lets any MICROSOFT™ WINDOWS™ application provide users a common way to work with digital identities.
Despite their diversity, digital identities all have one thing in common: when transmitted on the network, every digital identity is represented by some kind of security token. A security token is just a set of bytes that expresses information about a digital identity. This information includes one or more claims asserted to be true by the token's issuer, each of which contains some part of the total information conveyed about this identity. A simple security token might include only a claim containing a username, while a more complex one might include claims containing a user's first name, last name, home address, and more. Security tokens for some digital identities might also include claims that contain sensitive information such as credit card numbers.
With most security systems, some information is provided in order to prove that these claims really do belong to the user presenting them. One simple (and currently very common) way to do this is to send a password along with the claims. A more powerful approach is for the user to prove claims ownership using a private key associated with a public key that has been signed along with the disclosed claims by the issuer. Regardless of the method, the security tokens that represent digital identities commonly provide some kind of proof that allows a receiver of the token to verify that this token really does represent the person or organization presenting the token.
In the identity metasystem, users present certified claims to a Relying Party by retrieving a security token encoding the requested claims from the Identity Provider in real time. For example, the user may attempt to access a web page provided by the Relying Party, receive a request for identity verification, contact the Identity Provider to obtain a security token, and provide the security token to the Relying Party to access the web page. This approach creates privacy, security, and scalability problems. For example, the Identity Provider can track and trace the user's activities (especially if colluding with Relying Parties), can deny access to targeted users or impersonate them, and has to be highly reliable because it is involved in each user access. In addition, the Relying Party may receive more information about the user through the security token than is necessary for the user's purpose in interacting with the Relying Party.